Part one of this trilogy of articles offered some general advice on problem-solving drawn from my experience and training as a fire safety officer and systems analyst. Part three will offer more of the same, but the discussion in the first part had reached the point of considering the subject of setting priorities – a discussion that quickly ballooned into something altogether too large and important to be contained in what was originally planned to be a single article.

Prioritization is an essential skill for long-term success. In terms of problem-solving, the subject falls into four broad categories: Problem Definition, Solution Prioritization, Confluences, and Consequences & Repercussions. While I’m going to try and inject some rationality into the analyses of these different topics, in practice the results are a theoretical exercise that is not worth undertaking, so people tend to rely on gut instinct and cloak their decisions on whatever spurious and specious logic they can bring to bear. What’s needed are some practical shortcuts to put a little of that theoretical rigor into the analytic and decision-making processes – preferably something that can be applied mentally, without recourse to physical representations, but something that can be done on scraps of paper would be better than nothing.

Fortunately, I have just such a practical technique to offer – in fact, I have two of them – and they form two additional topics for this article.

So, theory and then practice. And now that we all know what the road map for this particular discussion is going to be, let’s dive right in…

Problem Prioritization

If you have half-a-dozen problems to solve, how do you decide the order of priority for solving them?

Sub-Problem Breakdown

Every problem that exists can be broken down into the steps required to solve it, each of which can be restated as a separate sub-problem. Looking at this situation from another perspective, each sub-problem can be considered a partial solution to the larger problem. This becomes important when one considers that a partial solution may be almost as good as a complete solution, but take a lot less time and effort.

A great example is creating the next adventure in an RPG campaign. So that’s the main problem. Coming up with an overall idea is the first step. Working out how the characters get involved with whatever the situation is the second. Roughing out the events between this beginning through to the end of the plotline is the third. Determining where those events are likely to occur, in general, is the fourth. Identifying the NPCs that are needed is the fifth. Generating rough drafts of any maps, props, character handouts, etc is the sixth. The seventh is actually generating those props, maps, etc. Eighth though Eleventh are detailed Narratives, Location Descriptions, Character Outlines, and Dialogue outlines.

It’s possible to run the adventure after the first sub-problem, but it would be better if more prep was done. Each of the steps through to the Seventh add to the preparedness to run the adventure, but it’s only when all seven are complete that a new level of preparedness is achieved that is greater than the sum of its parts. The next iteration develops details for each of the elements roughed out in steps two to five, and at the end of that process, the adventure is definitely ready to run. Further steps would be needed to evolve the adventure to a publishable standard, making it less focused on the specific individuals in a particular campaign and more comprehensive, able to cope with a variety of PCs, and so on, but that’s not the problem at hand.

Criticality

The more essential a solution is to an individual subproblem, the more critical that sub-problem can be considered to the solution of the overall problem. In theory, if you add up the criticality measures of each subproblem, you achieve a measure of how critical the main problem is. The flaw in this theory is that it assumes each subproblem is of equal importance, and it just ain’t so.

For example, you may have four tasks to try and get done for the next game session. One is preparing the adventure. Two is mapping the base of operations that the PCs have just acquired. Three is populating it with NPCs. Four is working out the details of the magic items that they liberated in the last adventure. Five is working out the consequences of any loose ends that the PCs left in previous adventures, and how these will affect the adventure. Now assume that you don’t have time to do all of the above.

Criticality, in the context of this example, is how urgently you need something for the next game session.

You could identify which one item is most critical and spend all your time on that one item. You could prepare each item to a limited extent and then focus your remaining time on the one most critical. Either is preferable to spending all your time on an item chosen at random, because the odds are four-to-one against your choosing the right one.

An example from a player’s perspective is: We have five problems to deal with. Which one is most urgent? Of course, you can’t judge without knowing the circumstances and identifying the five specific problems, so let’s invent some for the purposes of discussion: We’re broke, we’re starving, we’re cursed, our base of operations just burned down, and we’re being hunted by the authorities for crimes we didn’t commit. One solution would be to let yourselves get captured – they feed you in jail and give you a roof over your head, you don’t need money, and the curse provides a defense of sorts – but I don’t expect most PCs to be happy with that choice, they tend to want to be more proactive in solving their problems. Devoting exclusive attention to any one of these problems isn’t going to work very well. A set of partial solutions is needed just to get a platform from which each of the problems can be addressed properly. The most critical problem is being hunted by the authorities – a temporary solution to that problem requires disguises of some sort. Once that’s in hand, money can get some food and temporary lodgings to serve as a new base of operations. Next would probably be the curse, depending on just what it was – and which probably doesn’t have an intermediate or partial solution, they tend to be all-or-nothing. With that out of the way, the group can function effectively – but by this time, money and food are probably back on the agenda, and if money isn’t solved, the lodgings issue will also crop up again. More money is therefore the next priority – again, a short-term solution is probably good enough. Once that’s solved, the dangers of the disguises being penetrated are probably severe enough that preparing a new set, ready to go, would be a good idea. Only then can the problem with the authorities be targeted – probably by trying to identify who’s falsely accused them and why.

That’s certainly the plan of action I would outline if I were confronted with this set of issues in a game.

The key to developing that plan was distinguishing between two types of sub-problem: permanent or lasting solutions, and temporary, immediate solutions, then assigning relative levels of criticality to each subproblem – then tackling them in the order of the resulting priority. The plan was further refined by considering how long the temporary solution would hold, and adjusting the priorities accordingly.

Of course, other considerations could come into play – if one of the characters was especially recognizable, or the authorities had some means of magically tracking the characters, or complications of that nature. It’s not the only solution – circumstances might require money in order to obtain disguise materials. But this would still be the basic starting point.

These examples demonstrate two fundamental principles of criticality analysis:

• Total Criticality is equal to the sum of sub-problem criticalities; and
• Relative Criticality will vary from one problem to another.

Assessing the relative Criticality of each subproblem in terms of solving the overall problem gives an accurate measure of the criticality over time of the sub-problem. The flaw in doing so is that it assumes that each overall problem has the same priority. Correcting this requires multiplying those individual sub-problem criticalities by the overall priority rating of each larger problem to get a true relative measure of the criticality.

Confinement

Criticality is not the only principle illustrated by these examples. The second general principle is Confinement. As a general rule of thumb, some problems restrict what can be done about other problems – “being wanted” is the obvious one. Depending on the specifics, the “Curse” might be another. It follows that these problems, and their component sub-problems, should receive a greater priority than their Criticality alone, simply because even a partial solution expands the number of options open to the problem-solver, or increases the effectiveness of solution attempts.

Mathematically:

• Sub-problem Priority = (Criticality x Relative Adjustment) + Confinement Modifier.
• Problem Priority = Sum (Sub-problem priority 1 + sub-problem priority 2 + …)

Solution Practicality

Sometimes there’s just nothing you can do. This is usually the consequence of a blocking sub-item, also known as a dependency. It’s hard to have a confrontation with the supervillain in his lair until you’ve worked out the details of that lair – so the lair blocks completion of the confrontation adventure, which is dependant on completion of the lair.

Clearly, the priority of creating the lair (to use this example) is more than if it stood alone. The actual Sub-problem priority is the usual priority measure PLUS the usual priority measure of everything that depends on it – and everything that depends on it has it’s normal priority MINUS this contribution (effectively zero) until this sub-priority item is dealt with.

The reason for this behavior is because one item is completely dependant on the other, which is another way of saying that one item is impractical until another is completed. But there are degrees of impracticality; it might not be necessary to completely detail the lair, a general summary might be enough, or perhaps you intend to use a map from a commercial product and improvise the details as you go. or maybe there’s enough material in the adventure that all you need for the next game session is a location description – so, by subdividing the adventure, you can relieve the dependency.

Practicality is therefore a fraction applied to the imported part of the sub-problem priority measure. If half the circumstances or approaches permit work to proceed without the dependency then only half the total value of the dependant items gets attached.

Mathematically:

• Sub-problem Dependency Modifier = Practicality Ratio x Base Sub-problem priority.
• Child Dependency Priority = Base Sub-problem priority – Sub-problem Dependency Modifier
• Parent Dependency Priority = Base Sub-problem priority – Sub-problem Dependency Modifier

Interval Capacity

Dependence is not the only influence on Practicality, but to facilitate analysis I have chosen to deal with the time requirement as a separate factor.

So how should time requirements be assessed? This is where it gets really tricky.

In the order of highest sub-problem, priority, multiply each priority by the probability of getting that particular task finished in the time remaining after all the previous items are completed.

This creates moving goal posts, but the end result is that priority scores get assigned to each task, and then adjusted for the real-world factors that always get in the way.

Confluences

So that’s it, we’ve allowed for everything, right? Note quite. There remain two factors that a realistic analysis would have to take into account, and they are both Confluences.

Anyone skipping all the deep theory might want to start reading from here.

Commonality Of Subproblems

First, we have a confluence of sub-problems, i.e. tasks, to consider. Any time that you need the same starting point in order to complete two or more subsequent tasks, you have a confluence of tasks.

With a ‘flat’ structure – one in which each preliminary step required to achieve a task is specified – this results in the same task being listed multiple times and receiving multiple priority scores. That’s not right – each task should have one entry and one entry only. Having done something, you don’t have to do it again to use it for something else.

The correct approach is to add the two priority measures together to get a net score. And if that puts a priority weighting on tasks that can be used for multiple purposes, what’s wrong with that?

Community Of Solutions

There are times when even though an item isn’t meant for a specific purpose, it can be adapted to that purpose. A good example is an illustration that you draw inspiration from; it can be used not only for idea generation, but can replace or compliment a narrative section. When this is explicitly defined as part of the overall problem, it’s an example of a standard confluence, as described in the previous section; when it’s a lucky accident, it’s a non-standard confluence that has the potential to completely reshape the priorities regarding the rest of the problem, and (at the very least) should trigger a reassessment of the priorities assigned.

Logic therefore dictates that the greatest possible efficiency in terms of results vs time taken is achieved by “front-loading” those items that experience shows can have this sort of serendipitous outcome.

This actually defines a couple of alternative problem-solving strategies that are worth understanding.

Game-changers first
There is a fine balance between dealing with the game changers and deciding exactly what you are going to need to do. If you actually find something that radically reshapes the problem – which won’t happen all the time – then you avoid wasting time breaking down the problem into detailed requirements only to have to redo it all; but if you don’t then your work on the game-changers is going to be less efficient than it could have been, so you end up wasting time that way. Which is the bigger risk?

Personally, I think that if you have any clue at all as to what the basic shape of the solution is going to be, then your game-changer efforts are not entirely blind choices – so, in this circumstance, doing the game-changers first is the better choice. If you are completely ignorant as to the nature of the solution, then this solution is not the best.

Game-changers after problem breakdown
That’s when this alternative is the better choice. Essentially, it can be summed up: get a rough idea of the answer, then work on anything that might offer a shortcut.

Game-changers as a cumulative priority item
And one final alternative to contemplate: consider all the game-changers to be a single confluent priority item, add their priorities together as noted previously, and use that value to determine where they fall in the task list.

Consequences & Repercussions

There’s still one more wrinkle to contemplate in this theoretical picture. If it’s wrong to consider tasks or partial solutions in isolation within a problem, it’s even more incorrect to ignore the fact that work done to solve one problem can also contribute to the solution of another. Some tasks can act as an investment in future problem-solving – whether we’re talking about PC choices in a game, or GM choices in creating an adventure, or in crafting a campaign. Ideally, it can be argued, you want all the work done in the past to come together at the end of the campaign to free the GM completely from the burdens of his role so that he can sit back and just enjoy it as much as the players should.

There are all sorts of theoretical ways in which this factor could be accommodated, but none of them are especially compelling. Ultimately, this is so dependant on specifics that it can’t be properly incorporated into a theoretical model – especially one that will never be used in real life.

Getting Practical

So, if it’s never going to be used, why did I bother putting a lot of effort into thinking about the theoretical analysis that I’ve just spent almost 2500 words explaining?

If a practical model doesn’t reflect the theory, there’s a great chance that the practical solution won’t work properly, or at all. Practicality may force a compromise, but you have to know which corners you are cutting, and why. Before I could offer the approaches that I have in mind, I wanted to be sure they worked – and I wanted to be able to explain why they worked :)

Practical Methods 1: Lists and scores

The first practical method involves making a list and doing some quick-and-dirty scoring to get a priority.

Step 1: Make the list

Make a list of all the steps and substeps involved in achieving a solution. Number the initial breakdown as a zero. For each item, list it in two entries – summary and detailed – if that seems appropriate. The exception is anything that you define as a possible game-changer which gets placed in it’s own sub-list immediately after the general breakdown, but numbered as though it were in the appropriate place on the list.

Not clear? Try the following example list:

0. Overall Idea

20. PC Involvement in Adventure

30. Adventure Breakdown – summary

31. Adventure Breakdown – Detailed

40. Locations – summary
41. Locations – detailed

42. Locations – Illustrations

50. Maps – General outline/Notes

51. Maps – detailed

60. NPCs involved – summary
61. NPCs involved – descriptions
62. NPCs involved – details

63. NPCs involved – illustrations

70. Props – General Outline
71. Props – construction

80. Player Handouts – General Outline
81. Player Handouts – creation

90. Campaign Reference – General Requirements
91. Campaign Reference – Outline

92. Campaign Reference – Creation

These 21 steps are the essential components of creating an adventure, an act that should be familiar to all of us. The list above has everything in its logical sequence. Each major adventure component starts with a “ten number” – “10, 20, 30, 40” and so on – while subsequent steps within that adventure component have been given numbers going up by 1 – “31, 41, 42”, and so on. “10” has been reserved for the potential Game Changers.

You might be wondering what “Campaign Reference” entails. This is for anything rules or world-related not specifically aimed at this particular adventure. It could be a new character class, a new NPC race, a new monster, a new magic item, a new piece of campaign history, a new gadget, or a change to the House Rules. The entire “Orcs and Elves” series falls into this category.

If I now extract all the things that I consider potential game changers and put them into their own category under the “10” entry, I get:

0. Overall Idea

10. Game-changers
11. (30) Adventure Breakdown – summary
12. (42) Locations – Illustrations
13. (50) Maps – General outline/Notes
14. (60) NPCs involved – summary
15. (63) NPCs involved – illustrations
16. (90) Campaign Reference – General Requirements
17. (91) Campaign Reference – Outline

20. PC Involvement in Adventure

31. Adventure Breakdown – Detailed

40. Locations – summary
41. Locations – detailed

51. Maps – detailed

61. NPCs involved – descriptions
62. NPCs involved – details

70. Props – General Outline
71. Props – construction

80. Player Handouts – General Outline
81. Player Handouts – creation

92. Campaign Reference – Creation

Step 2: Criticality Ranking

In each group of “10s”, starting with 20, assign a value to the highest-numbered item – do it with tally marks – that ranks them in order of criticality. High is more critical. How essential is this item to having the adventure (in this case) in a playable state?

In the case of our example, the entries to be listed are those numbered 00, 20, 31, 42, 51, 63, 71, 81, and 92.

Then do the items that precede these entries in each group; the only rule is that each one MUST be given a criticality score higher than, or equal to, it’s successor. Keep going until every item has a criticality rating.

0. Overall Idea IIII  IIII

10. Game-changers
11. (30) Adventure Breakdown – summary IIII III
12. (42) Locations – Illustrations III
13. (50) Maps – General outline/Notes IIII
14. (60) NPCs involved – summary IIII II
15. (63) NPCs involved – illustrations III
16. (90) Campaign Reference – General Requirements IIII II
17. (91) Campaign Reference – Outline IIII I

20. PC Involvement in Adventure II

31. Adventure Breakdown – Detailed IIII

40. Locations – summary IIII II
41. Locations – detailed III

51. Maps – detailed I

61. NPCs involved – descriptions IIII
62. NPCs involved – details III

70. Props – General Outline II
71. Props – construction I

80. Player Handouts – General Outline IIII II
81. Player Handouts – creation IIII I

92. Campaign Reference – Creation IIII

Step 3: Dependency

If an item is directly dependant on a previous item, add 2 to the parent item’s tally.

Add 2 to the tally of each item in the game-changing category.

Then arbitrarily increase the initial step (00) to match that of the highest item if it doesn’t already.

0. Overall Idea IIII  IIII  IIII  IIII  IIII III

10. Game-changers
11. (30) Adventure Breakdown – summary IIII  IIII  IIII  IIII  IIII III
12. (42) Locations – Illustrations IIII
13. (50) Maps – General outline/Notes IIII IIII
14. (60) NPCs involved – summary IIII  IIII IIII
15. (63) NPCs involved – illustrations IIII
16. (90) Campaign Reference – General Requirements IIII  IIII I
17. (91) Campaign Reference – Outline IIII  IIII

20. PC Involvement in Adventure II

31. Adventure Breakdown – Detailed IIII  IIII

40. Locations – summary IIII  IIII I
41. Locations – detailed III

51. Maps – detailed I

61. NPCs involved – descriptions IIII IIII
62. NPCs involved – details III

70. Props – General Outline IIII
71. Props – construction I

80. Player Handouts – General Outline IIII IIII
81. Player Handouts – creation IIII I

92. Campaign Reference – Creation IIII

Step 4: Reorder by Tally Count

The next step is to get each step into order by tally count. I’ve put the tally totals in brackets afterwards, because that makes it a little easier to reorder the list. At this point, you can also forget the old index numbers at the start of each entry. Just to avoid confusion, I will normally number the sorted steps starting at 100.

100. Overall Idea IIII  IIII  IIII  IIII  IIII III (28)
101. Adventure Breakdown – summary IIII  IIII  IIII  IIII  IIII III (28)
102. NPCs involved – summary IIII  IIII IIII (14)
103. Campaign Reference – General Requirements IIII  IIII I (11)
104. Locations – summary IIII  IIII I (11)
105. Campaign Reference – Outline IIII  IIII (10)
106. Adventure Breakdown – Detailed IIII  IIII (10)
107. Maps – General outline/Notes IIII IIII (9)
108. NPCs involved – descriptions IIII IIII (9)
109. Player Handouts – General Outline IIII IIII (9)
110. Player Handouts – creation IIII I (6)
111. Locations – Illustrations IIII (5)
112. NPCs involved – illustrations IIII (5)
113. Campaign Reference – Creation IIII (5)
114. Props – General Outline IIII (4)
115. Locations – detailed III (3)
116. NPCs involved – details III (3)
117. PC Involvement in Adventure II (2)
118. Maps – detailed I (1)
119. Props – construction I (1)

Step 5: Done!

Believe it or not, this incorporates almost everything discussed in the theory section – in a relatively simple and crude fashion. This particular set of instructions yields the “Game-changers after problem breakdown” strategy discussed earlier; it works if you have a rough idea of what the adventure is going to be about before you start. If you don’t, and want to employ the “game changers first” approach, simply skip the “arbitrary” renumbering of the old “00” item and place it immediately before the detailed adventure breakdown.

The result is a task list, in the order in which each task is to be carried out. You can simply tackle it in order until you run out of time, or you can use it to budget your available prep time, as you see fit.

Of course, this is a generic solution; in any particular real-world situation, some tasks may have different rankings because they have (in whole or in part) already been done in the creation of earlier adventures, or because you don’t perform any given step – not everyone will go looking for pictures to illustrate their NPCs, for example; they either have them already (because they are taking the NPC from an existing product) or they’ll do without and rely on narrative descriptions.

Practical Methods 2: The notes array

In some ways, an even simpler approach is to put each item on a card or post-it note and simply shuffle them down and across as necessary instead of fussing around with tallies. When I use this approach, the starting layout is always “tens down, ones across”, as shown by the illustration to the right. This naturally lines up dependencies to the left.

Then move game-changers to the left of their respective stacks to form a new column, move the “00” to the left or right of that (depending on whether you want to use the first or second of the strategies on offer). Close up any gaps by shifting cards to the left.

Once that’s done, order items in each column according to priority, moving any cards/notes to the right of the card whose order is being adjusted.

Finally, pick up the cards starting at the bottom right and working up each column before starting the next leftmost column. Once again, the result is a task list in order.

This approach has one big advantage – you can easily tweak the order. Working on an NPC might give you an idea for a location, or an event, or whatever – this permits you to shuffle things around to strike while the iron is hot.

Looking ahead to part three

Having completed our side-excursion into theory and emerged back into the realm of practical advice, it’s full-steam-ahead with more problem-solving techniques next time, as this series races to a conclusion!